In many digital communication protocols, and particularly time division multiplex (TDM) protocols, digital data is transmitted in frames, where a frame comprises a plurality of time slots, each time slot corresponding to a transmitted digital symbol (e.g., a bit). As is well known in the art, in a frame, some of the time slots may be dedicated to communication protocol housekeeping information while the remaining time slots are dedicated to actual data communicated between two digital devices. The housekeeping data is usually transmitted at the beginning or the end of the frame. Also as is well known to those of skill in the art, in TDM systems, one or more time slots in a frame are dedicated to a particular communication session between two particular digital devices, while other time slots are dedicated to other communication sessions. Accordingly, multiple communication sessions can be carried on simultaneously.
Many different communication protocols are in use for TDM and other frame-based digital communication paradigms. However, most, if not all, include at least three signal lines, namely, a clock line, a frame synchronization line and a data line. All communication timing is keyed off of the clock, which typically runs at the communication data bit rate of the system or a multiple thereof. Obviously, the actual data being exchanged between two devices is transmitted on the data line (if serial) or lines (if parallel). The frame synchronization (or frame sync) line carries a signal that delimits the beginning of each frame. Commonly, the beginning of the frame is delimited by a rising or falling edge on the frame sync line. All of the transmitting and receiving devices synchronize themselves to the frame sync signal so that they will be able to transmit and receive the symbols within the appropriate time slots.
In accordance with many digital communication protocols, the clock and or frame sync signal is always generated by the transmitting device. Other protocols allow or even require one particular device to generate the clock and/or the frame sync signal for another device (or devices). One such protocol is the Integrated Packet Bus (IPB) specification promulgated by the Advanced Communication Riser (ACR) Special Interest Group (SIG). The ACR IPB specification is a protocol particularly designed for communication between a CPU in a personal computer and peripheral devices, particularly communications peripherals, such as home networking hubs, ethernet hubs, modems, DSL modems, cable modems, etc. The ACR IPB specification speaks in terms of a controller and one or more targets. As is well known in the art of general purpose, personal computer design, the trend has been to push out all handling of communications between the CPU and other devices, including peripherals to a dedicated chip, termed the controller. In accordance with the IPB specification, part of the functionality of the controller would be to carry out communications with appropriate target devices, such as the aforementioned modems and networking hubs using the ACR IPB protocol. Typically, the controller will provide the functionality for communicating with other devices also. Under the ACR IPB specification, the bus between the controller and the one or more target devices comprises six lines, namely, a received direction clock (RDCLK), a transmit direction clock (TDCLK), a receive direction frame synchronization signal (RDFRAME), a transmit direction frame synchronization signal (TDFRAME), a transmit direction data line (DATAOUT) for data transmitted from the controller to the target device, and a receive direction data line (DATAIN). In ACR IPB, the transmit direction is the direction from the controller to the target device and the receive direction is the direction from the target device to the controller. Under the ACR IPB protocol, the TDCLK and TDFRAME signals are used for timing in the transmit direction are generated at the controller. In addition, the RDFRAME signal is generated at the controller. Under the ACR IPB protocol, the RDCLK signal can be generated by either the controller or the transmitting target device.
In digital communication protocols in which the clock or frame sync signal for given set of transmission data is generated by a device other than the transmitting device, a delay skew issue arises.
For instance, consider the timing diagrams of FIGS. 1A and 1b. FIG. 1A illustrates an exemplary timing situation for transmit direction data in accordance with the ACR IPB protocol. In accordance with the protocol, the first bit of data, B0 in a frame begins being transmitted by the controller at time T1 at the beginning of the second clock cycle after the leading edge of the frame synchronization signal. In this example, the leading edge of the frame sync signal occurs at time T0 and, for sake of illustrating a worst case scenario, the first clock edge on TDCLK is essentially simultaneous therewith (but late enough to be counted as the first clock edge after the frame sync).
Accordingly, one full clock cycle later, at time T1, the controller begins to transmit the first bit of data. Thus, that data bit becomes fully valid at time T1+δ. At the falling edge of that clock cycle, at time T2 (note that we are assuming a 50% duty cycle for TDCLK), the receiving target device samples the DATAOUT line to read the bit value. The process then continues for each clock cycle until the end of the frame.
Thus, for example, at T3 (the third rising edge of TDCLK after the beginning of the frame), the controller begins transmitting the second bit. That second bit becomes fully valid at time T3+δ and then is sampled by the receiving target device at time T4 (the falling edge half-way through that clock cycle). Since the TDFRAME, TDCLK and DATAOUT signals are all sourced from the same location (i.e., the controller), there are no delay skew issues. Particularly, even though there is some finite time lapse between the transmission of TDCLK, TDFRAME and DATAOUT from the controller and their receipt at the receiving target device, the delay is essentially equal for all three lines.
However, in the receive direction, if the RDCLK and RDFRAME signal are sourced from the controller, while the DATAIN signal is sourced from the transmitting target device, delay skew becomes an issue. For instance, let us consider the example of FIG. 1B. The timing in the example of FIG. 1B differs from that of FIG. 1A in two respects. First, the clock and frame signals are sourced from the controller, whereas the data is sourced from the transmitting target device. Secondly, the first bit of data goes out on the next clock edge (i.e., half of a clock cycle) after the first clock edge after the frame sync signal, instead of a full clock cycle after the first clock edge after the frame sync signal.
This situation presents two potential timing problems. First, if the clock rate is very fast, the transmitting target device simply may not be able to generate the first bit of the frame within the allotted time. Particularly, FIG. 1B illustrates something close to a worse case scenario in which the first clock edge after the frame sync signal occurs essentially simultaneously with the frame sync signal at time T0, but late enough to be counted as the first clock edge after the frame sync. Then the transmitting target device has only until T1, i.e. half a clock cycle later, to output the first bit of data. Some delay past T1 is acceptable, because that data really only needs to be fully valid by time T2 when the controller will read the data. Accordingly, the target device has slightly less than one full clock cycle after the frame sync to output fully valid data. At very high clock speeds, this may be very difficult to achieve. For instance, the ACR IPB specification specifies a 40 MHz data rate, which could make it very difficult for a transmitting target device to place the data in the first bit position of a frame in time.
A second timing issue arises due to delay skew since the clock and frame signals are sourced from the controller, but the data is sourced from the target device. Particularly, as previously noted, the transmitting device will begin transmitting a bit at the leading edge of a clock cycle and that data must be fully valid at the transmitting device at the midpoint edge of that clock cycle. However, there is some finite delay between the time the controller generates the leading edge of that clock cycle and the time that it is received at the target device. Further, there is a delay between the time the transmitting target device generates the data and the time it is received at the receiving controller. The sum of these two delays is called round trip delay. The round trip delay includes not only the path delay but printed circuit board delay and, possibly, a connector delay as well as internal device delays. If the round trip delay is greater than half a clock cycle (assuming a 50% duty cycle), the data cannot arrive at the controller by the time the controller samples for that bit.
Thus, referring to FIG. 1B, the controller experiences the first clock edge after the frame sync at time T0, and expects the target device to begin transmitting the data at time T1, and will sample for the data at time T2, just as in FIG. 1A. However, the target device experiences the first clock edge after the frame sync at time T0+Δ and begins transmitting the bit at time T1+Δ. Even further, the controller actually receives the beginning of the transmission of the data at time T1+2Δ. Of course, we also must add in the delay, δ, between the transmitting device commencing transmission of that bit and the bit value becoming fully valid. Accordingly, the data is not fully valid at the receiving controller until time T1+2Δ+δ. If 2Δ+δ is greater than a half clock cycle (as shown in FIG. 1B), the data will not reach the controller after time T2 when the controller looks for the data.